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Dynamic Hostname Exchange Mechanism for OSPF 
Abstract 


This document defines a new OSPF Router Information (RI) TLV that 
allows OSPF routers to flood their hostname-to-Router-ID mapping 
information across an OSPF network to provide a simple and dynamic 
mechanism for routers running OSPF to learn about symbolic hostnames, 
just like for routers running IS-IS. This mechanism is applicable to 
both OSPFv2 and OSPFv3. 


Status of This Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 
Official Protocol Standards" (STD 1) for the standardization state 
and status of this protocol. Distribution of this memo is unlimited. 


Copyright Notice 


Copyright (c) 2009 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents in effect on the date of 
publication of this document (http://trustee.ietf.org/license-info). 
Please review these documents carefully, as they describe your rights 
and restrictions with respect to this document. 


This document may contain material from IETF Documents or IETF 
Contributions published or made publicly available before November 
10, 2008. The person(s) controlling the copyright in some of this 
material may not have granted the IETF Trust the right to allow 
modifications of such material outside the IETF Standards Process. 
Without obtaining an adequate license from the person(s) controlling 
the copyright in such materials, this document may not be modified 
outside the IETF Standards Process, and derivative works of it may 
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not be created outside the IETF Standards Process, except to format 
it for publication as an RFC or to translate it into languages other 
than English. 
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1. Introduction 


OSPF uses a 32-bit Router ID to uniquely represent and identify a 
node in the network. For management and operational reasons, network 
operators need to check the status of OSPF adjacencies, entries in 
the routing table, and the content of the OSPF link state database. 
When looking at diagnostic information, numerical representations of 
Router IDs (e.g., dotted-decimal or hexadecimal representations) are 
less clear to humans than symbolic names. 


One way to overcome this problem is to define a hostname-to-Router-ID 
mapping table on a router. This mapping can be used bidirectionally 
(e.g., to find symbolic names for Router IDs and to find Router IDs 
for symbolic names) or unidirectionally (e.g., to find symbolic 
hostnames for Router IDs). Thus, every router has to maintain a 
table with mappings between router names and Router IDs. 


These tables need to contain all names and Router IDs of all routers 
in the network. If these mapping tables are built by static 
definitions, it can currently become a manual and tedious process in 
operational networks; modifying these static mapping entries when 
additions, deletions, or changes occur becomes a non-scalable process 
very prone to error. 


This document analyzes possible solutions to this problem (see 
Section 2) and provides a way to populate tables by defining a new 
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OSPF Router Information TLV for OSPF, the Dynamic Hostname TLV (see 
Section 3). This mechanism is applicable to both OSPFv2 and OSPFv3. 


1.1. Specification of Requirements 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


2. Possible Solutions 


There are various approaches to providing a name-to-Router-ID mapping 
service. 


One way to build this table of mappings is by static definitions. 

The problem with static definitions is that the network administrator 
needs to keep updating the mapping entries manually as the network 
changes; this approach does not scale as the network grows, since 
there needs to be an entry in the mapping table for each and every 
router in the network, on every router in the network. Thus, this 
approach greatly suffers from maintainability and scalability 
considerations. 


Another approach is having a centralized location where the name-to- 
Router-ID mapping can be kept. The DNS could be used for this. A 
disadvantage with this centralized solution is that it is a single 
point of failure; and although enhanced availability of the central 
mapping service can be designed, it may not be able to resolve the 
hostname in the event of reachability or network problems, which can 
be particularly problematic in times of problem resolution. Also, 
the response time can be an issue with the centralized solution, 
which can be equally problematic. If the DNS is used as the 
centralized mapping table, a network operator may desire a different 
name mapping than the existing mapping in the DNS, or new routers may 
not yet be in the DNS. 


Additionally, for OSPFv3 in native IPv6 deployments, the 32-bit 
Router ID value will not map to IPv4-addressed entities in the 
network, nor will it be DNS resolvable (see Section 4). 


The third solution that we have defined in this document is to make 
use of the protocol itself to carry the name-to-Router-ID mapping in 
a TLV. Routers that understand this TLV can use it to create the 
symbolic name-to-Router-ID mapping, and routers that don’t understand 


it can simply ignore it. This specification provides these semantics 
and mapping mechanisms for OSPFv2 and OSPFv3, leveraging the OSPF 
Router Information (RI) Link State Advertisement (LSA) ([RFC4970]). 
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3; 


3: 


Implementation 


This extension makes use of the Router Information (RI) Opaque LSA, 
defined in [RFC4970], for both OSPFv2 and OSPFv3, by defining a new 
OSPF Router Information (RI) TLV: the Dynamic Hostname TLV. 


The Dynamic Hostname TLV (see Section 3.1) is OPTIONAL. Upon receipt 
of the TLV, a router may decide to ignore this TLV or to install the 
symbolic name and Router ID in its hostname mapping table. 


1. Dynamic Hostname TLV 
The format of the Dynamic Hostname TLV is as follows: 


0 a 2 3 
Od 232 4G 16 F889 OP V2 Be ANG. 68 19. OU 2° Bi 4-56 FBO Oecd 
+-4+-4-4-4-4-4+-4-4+-4+-4+-4-4-4-4+-4-4+-4+-4+-4+-4+-4+-4-4-4-4-4-4-4-4-4-4-4 
| Type | Length | 
+-4+-4-4-4-4-4-4-4-4+-4-4+-4-4+-4+-4-4+-4+-4-4-4-4+-4+-4-4-4-4+-4+-4-4-4-4-4 
| Hostname ... | 
+-4+-4-4+-4-4-4-4-4-4-4-4+-4+-4-4+-4-4+-4+-4-4-4+-4-4-4-4-4-4-4-4-4-4-4-4 


Type Dynamic Hostname TLV Type (7; see Section 6) 


Length Total length of the hostname (Value field) in octets, not 
including the optional padding. 


Value Hostname, a string of 1 to 255 octets, padded with zeroes to 
4-octet alignment, encoded in the US-ASCII charset. 


Routers that do not recognize the Dynamic Hostname TLV Type ignore 
the TLV (see [RFC4970]). 


The Value field identifies the symbolic hostname of the router 
originating the LSA. This symbolic name can be the Fully Qualified 
Domain Name (FQDN) for the Router ID, it can be a subset of the FQDN, 
or it can be any string that operators want to use for the router. 
The use of FQDN or a subset of it is strongly recommended since it 
can be beneficial to correlate the OSPF dynamic hostname and the DNS 
hostname. The format of the DNS hostname is described in [RFC1035] 
and [RFC2181]. If there is no DNS hostname for the Router ID, if the 
Router ID does not map to an IPv4-addressed entity (e€.g., see 
Section 4), or if an alternate OSPF dynamic hostname naming 
convention is desired, any string with significance in the OSPF 
routing domain can be used. The string is not null-terminated. The 
Router ID of this router is derived from the LSA header, in the 
Advertising Router field of the Router Information (RI) Opaque LSA. 
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The Value field is encoded in 7-bit ASCII. If a user-interface for 
configuring or displaying this field permits Unicode characters, that 
user-interface is responsible for applying the ToASCII and/or 
ToUnicode algorithm as described in [RFC3490] to achieve the correct 
format for transmission or display. 


The Dynamic Hostname TLV is applicable to both OSPFv2 and OSPFv3. 
3.1.1. Flooding Scope 

The Dynamic Hostname TLV MAY be advertised within an area-local or 

autonomous system (AS)-scope Router Information (RI) LSA. But the 


Dynamic Hostname TLV SHOULD NOT be advertised into an area in more 
than one RI LSA, irrespective of the scope of the LSA. 


In other words, if a router originates a Dynamic Hostname TLV with an 
IGP domain (AS) flooding scope, it SHOULD NOT send area-scoped 
Dynamic Hostname TLVs except into any attached Not-So-Stubby Area 
(NSSA) area(s). Similarly, if a router originates an area-scoped 
Dynamic Hostname TLV (other than NSSA area scoped), it SHOULD NOT 
send an AS-scoped Dynamic Hostname TLV. When the Dynamic Hostname 
TLV is advertised in more than one LSA (e.g., multiple area-scoped 
LSAs, or AS-scoped LSAs plus NSSA area-scope LSA(s)), the hostname 
SHOULD be the same. 


If a router is advertising any AS-scope LSA (other than Dynamic 
Hostname TLV RI LSA), such router SHOULD advertise Dynamic Hostname 
TLV RI LSA in AS scope. Otherwise, it SHOULD advertise Dynamic 
Hostname TLV RI LSA in area scope. For example, an AS boundary 
router (ASBR) SHOULD send an AS-scope Dynamic Hostname TLV, whereas 
area boundary router (ABRs) and internal routers SHOULD send an area- 
scope Dynamic Hostname TLV. 


The flooding scope is controlled by the Opaque LSA type in OSPFv2 and 
by the S1 and S2 bits in OSPFv3. For area scope, the Dynamic 
Hostname TLV MUST be carried within an OSPFv2 Type 10 RI LSA or an 
OSPFv3 RI LSA with the S1 bit set and the S2 bit clear. If the 
flooding scope is the entire routing domain (AS scope), the Dynamic 
Hostname TLV MUST be carried within an OSPFv2 Type 11 RI LSA or 
OSPFv3 RI LSA with the S1 bit clear and the S2 bit set. 


3.1.2. Multiple OSPF Instances 


When an OSPF Router Information (RI) LSA, including the Dynamic 
Hostname TLV, is advertised in multiple OSPF instances, the hostname 
SHOULD either be preserved or include a common base element. It may 
be useful for debugging or other purposes to assign separate 
instances different hostnames with a consistent set of suffixes or 
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prefixes that can be associated with a specific instance -- in 
particular, when an instance is used for a discrete address family or 
non-routing information. 


4. IPv6 Considerations 


Both OSPFv2 and OSPFv3 employ Router IDs with a common size of 32 
bits. In IPv4, the Router ID values were typically derived 
automatically from an IPv4 address either configured on a loopback or 
physical interface defined on the local system or explicitly defined 
within the OSPF process configuration. With broader deployment of 
IPv6, it’s quite likely that OSPF networks will exist that have no 
native IPv4-addressed interfaces. As a result, a 32-bit OSPF Router 
ID will need to be either explicitly specified or derived in some 
automatic manner that avoids collisions with other OSPF routers 
within the local routing domain. 


Because this 32-bit value will not map to IPv4-addressed entities in 
the network, nor will it be DNS resolvable, it is considered 
extremely desirable from an operational perspective that some 
mechanism exist to map OSPF Router IDs to more easily interpreted 
values -- ideally, human-readable strings. This specification 
enables a mapping functionality that eases operational burdens that 
may otherwise be introduced with native deployment of IPv6. 


5. Security Considerations 


Since the hostname-to-Router-ID mapping relies on information 
provided by the routers themselves, a misconfigured or compromised 
router can inject false mapping information, including a duplicate 
hostname for different Router IDs. Thus, this information needs to 
be treated with suspicion when, for example, doing diagnostics about 
a suspected security incident. 


There is potential confusion from name collisions if two routers use 
and advertise the same dynamic hostname. Name conflicts are not 
crucial, and therefore there is no generic conflict detection or 
resolution mechanism in the protocol. However, a router that detects 
that a received hostname is the same as the local one can issue a 
notification or a management alert. 


The use of the FQDN as OSPF dynamic hostname potentially exposes 
geographic or other commercial information that can be deduced from 
the hostname when sent in the clear. OSPFv3 supports confidentiality 
via transport mode IPsec (see [RFC4552]). OSPFv2 could be operated 
over IPsec tunnels if confidentiality is required. 
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8. 


8. 


This document raises no other new security issues for OSPF. Security 
considerations for the base OSPF protocol are covered in [RFC2328] 
and [RFC5340]. The use of authentication for the OSPF routing 


protocols is encouraged. 

TANA Considerations 

IANA maintains the "OSPF Router Information (RI) TLVs" registry 
[IANA-RI]. An additional OSPF Router Information TLV Type is defined 
in Section 3. It has been assigned by IANA from the Standards Action 
allocation range [RFC4970]. 


Registry Name: OSPF Router Information (RI) TLVs 


Type Value Capabilities Reference 
7 OSPF Dynamic Hostname This document 
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